Using a Programming Language for Digital System Design

ion. The language must provide an abstraction mechanism—that is, a means of building large systems from smaller, HDL-modeled components. The two main methods of composing large systems are procedure calls and declarative blocks. Designers typically use the latter to describe a netlist of blocks in which component instances are bound by shared variables. These blocks are useful in modeling structural components. It may also be necessary for the designer to represent an external view of the component independent from its implementation(s). Thus, the interface specification must be separate from the component’s body specification. Such a feature is useful for iteratively refining a hardware model through successive implementations, without altering the external view of the component. Reactive programming. As mentioned earlier, hardware models are best represented as nonterminating programs in continuous interaction with their environment. It is easy to capture nonterminating interaction with programming languages that use control constructs such as while loops, but these structures severely constrain implementation and event handling in a concurrent environment. For hardware modeling, reactivity requires the basic mechanisms of synchronization and exception handling. The following are typical HDL constructs for modeling these mechanisms: ■ wait(condition) can specify a fixed amount of delay or an event occurrence. Its implementation can either translate it as a busy-wait loop (while(!condition);) or associate it with a specific communication structure (for example, event broadcasting in the Esterel programming language1). Typically, designers use wait to synchronize operations across simultaneously active modules. In languages that do not assume an implicit communication structure, it also explicitly specifies communication structures for data transfers among hardware modules. ■ watching(port or condition) {block} can be associated with an event (an action instance such as I/O, assignment, or condition setting) for a given block. Designers typically use watching to model the hardware’s handling of interrupt events. HDLs that provide this construct are considerably more powerful than traditional programming languages and other models. For instance, Esterel provides watching by encasing a behavior in a do {block} watching signal. As the number of these signals (or interrupts) increases, an equivalent finite-state model’s size increases exponentially, whereas the Esterel program grows only linearly. ■ disable(name) provides limited exception handling, such as termination of a block of behavior associated with a specific exception condition. Hierarchical disable operations (in Verilog, for example) execute and/or terminate specific process blocks to prescribe the extent of the exception handling. The net effect of using disable to suspend execution of a simultaneously active process is to issue an interrupt on the named process. In other words, disable is a senderside analog of watching. Determinism. At any level of abstraction, system simulation should be predictable, yielding the same outputs from the same sequence of inputs. Although a modeled behavior may be nondeterministic or even indeterminate4—that is, we may not have complete information to predict this unique behavior—we can always decompose it into deterministic parts. Simultaneity. We often need simultaneous actions to model hardware’s inherent parallelism. One programminglanguage mechanism for modeling parallelism is concurrent compositions. In these compositions, concurrency control is critical. We usually introduce serialization in concurrent compositions if a dependency exists between concurrent actions or if one of the actions represents a break in the control flow. Serialization preserves the natural semantics of continue and break statements. Using concurrency to model hardware parallelism is not very efficient for two main reasons. First, in process-level concurrency,5 communication is a synchronizing activity. In contrast, parallel hardware actions often proceed independently, and even in cases where the actions communicate, rarely do they require explicit synchronization. Second, during interpretation, the time synchronization takes is un.